Streaming multimedia content and/or data live over a communication network, especially when large scales of users may subscribe to and request content and/or data, presents a number of obstacles such as network outages, connectivity issues, unusual ingest formats, temporary breaks in stream, and the like. Robust content delivery techniques that are scalable, resilient against network or device glitches, breaks in a broadcast stream, connectivity issues, and the like, while also minimizing errors in underlying content such as unsynchronized audio and visual elements in video, shortened recordings (cut off at the end or beginning), recordings split into multiple files, and the like, exist in the context of live streaming, but do not also address such errors in connection with buffering of such streams for later, limited time-delayed (DVR, or digital video recording) access or in connection with full recording for later VOD (video-on-demand) access.
Further, recording multimedia data in traditional content delivery systems typically requires a broadcast to end (e.g., terminate) before any recording of the broadcast can be accessed or manipulated, which is especially bothersome in the case of very long broadcasts. For example, highlight videos cannot be created while a live-streamed sports match is still going. The broadcaster, using a traditional content delivery system, either has to stop and restart ingesting, which risks losing portions of the broadcast, or wait until the end of the broadcast for editing, which detracts from the immediacy of live video.
Moreover, traditional content delivery systems create and store differently formatted content and/or data for each specific supported client format (Mac, Windows, Android, iOS, and the like), and often must store such content and/or data in chunks of multiple sizes or lengths based on storage optimization considerations or format requirements (for example, three-second long video chunks in a proprietary format optimized for storage, and five-second long video chunks in MPEG-TS format for use with iOS clients), which takes up computing resources for transcoding as well as storage space, since multiple versions of the same content must be created and stored. For example, in certain instances, broadcasters may create/store multiple versions of the same VOD content with different QoS parameters (e.g., bit rates, etc.) specific to a type of requesting client device in order to properly serve the requesting client device; e.g., a mobile device may have different QoS parameters than a large television.
From a service provider point of view, merely introducing a separate recording architecture (e.g., limited time-delayed (DVR, or digital video recording) access, full recording for later VOD (video-on-demand), etc.) to a live content delivery system is not ideal. For example, introducing a separate recording architecture to a live streaming system, including buffering and/or recording architectures, may result in increasing a number of possible errors.